Concentric Openness

How Holonic Architecture Escapes the Ontology Unification Trap

by Kurt Cagle & Chloe Shannon

---

There has long been a tradeoff between two competing principles in ontology design. The first holds that a knowledge graph should represent a single persistent ontological model, pervasive throughout an organisation — and, ideally, between organisations. In this vision, an ontologist creates a single unifying model, and everything conforms to it. If everyone adheres to the standard, you achieve, in theory, complete interoperability of data, managed from a single authoritative source.

The unified ontology is, in this sense, the enterprise data equivalent of Esperanto: elegant in conception, and perpetually deferred in practice.

---

The Reality on the Ground

Department A has standardised on one database — or set of databases. Department B has standardised on a second. These databases were largely authored not by formal data modellers but by programmers working in isolation, at different times, on different applications. When those systems are ported into a knowledge graph, whatever happened to be in the relational model comes with them, changed as little as possible, because each application has evolved around that implicit ontology. The result is overlapping terms and structures that often disagree violently from one application to the next — not because the people involved were careless, but because there was no central agreement on terms and no appetite to rewrite functioning applications from scratch.

Different parts of an organisation evolve in different ways. The unification of data silos is therefore genuinely difficult: different identity keys, different conceptual classifications, different data shapes, different exposed properties. Each domain has developed its own working model of the world, and that model is load-bearing.

One of the most persistent shibboleths of the Open World Assumption compounds this problem: the idea that all data should be exposed to all parties equally. PII and PHI — personally identifiable and protected health information — are frequently invoked as the reason we cannot have fully open knowledge graphs. And they are real concerns. But they represent a small fraction of the data generated within any organisation. The real privacy problem is not primarily about individuals being tracked; it is about the structural mismatch between what different parts of an organisation need to know, and what they are equipped to handle, about the same subjects.

The privacy argument, in other words, is a red herring. The deeper issue is domain specialisation.

---

The Holon Principle

A holon is a whole that is simultaneously a part of a larger whole — the structural unit that best describes how complex organisations actually work. An organisation can be decomposed into sub-organisations, each of which performs a distinct set of functions and consequently generates and synthesises different kinds of information.

The HR department handles different information about a person than the sales department. Manufacturing holds different information about a product than research does. These holons — sub-organisations — may discuss the same individual, product, or location, but what they have to say about it differs substantially. The data they work with represents specialised knowledge of their domain, and the lens through which they observe an entity depends not only on the entity itself but on the identity and role of the observer.

This is not a flaw to be engineered away. It is the natural structure of any complex organisation, and an effective knowledge architecture should work with it rather than against it.

---

Encapsulation: Limiting What Can Be Asked

A holon, most importantly, needs to limit what questions can be asked — and by whom.

Most data systems are built on the assumption that any query against any data is permissible, subject to authentication. This creates two structural problems. First, a querant generally does not know the schema or its constraints, making query construction itself problematic; you cannot write a meaningful SPARQL query against a graph whose shape you cannot see. Second, an open query gives the querant the ability to reach information that may be sensitive, restricted, or simply irrelevant to their function.

Named parametric queries — vetted in advance and governed by the same rigour as schema constraints, ontologies, and inference rules — provide a far more disciplined approach. Rather than exposing the graph to arbitrary interrogation, they establish projections of the graph: well-defined views appropriate to particular roles or contexts. The querant receives exactly what they need to see. The interior structure of the holon is not disclosed unless it needs to be.

This is, recognisably, encapsulation — the foundational principle of object-oriented design — applied to graphs.

Such encapsulation is typically built around profiles rather than individuals. A senior officer within an organisation may be able to see substantially more information about an employee than someone in manufacturing or marketing. But the person in marketing may, in turn, see different information through their profile than a CEO would, because their role gives them specialised access relevant to their function. Access is not simply a matter of rank; it is a matter of role and context.

---

The Transformation Problem — and How It Has Changed

Historically, creating the relevant projections — the transformation from an internal ontology to an external one — was prohibitive. Writing complex SPARQL queries or SHACL rulesets capable of accurately mapping one ontological model to another required deep specialised expertise, and the cost of developing and maintaining those mappings was often enough to kill federated graph initiatives before they started.

That constraint is lifting.

If a source and target ontology are both known, a large language model is now quite capable of generating most or all of the required transformation logic. This is one of those practical inflection points that does not always make the theoretical literature but changes what is economically feasible in the field. A transformation that might once have required weeks of careful expert work can now be drafted in minutes and refined iteratively. Once established, it can be persisted as a named SPARQL Update or a SHACL ruleset — a deterministic, repeatable function that generates the external projection from the internal graph. The AI cost is incurred once, at authoring time. From that point forward, the transformation runs as ordinary infrastructure.

The external projection — the “outside view” of an agent or set of agents — may use equivalent terms to the interior model, or entirely different ones; it may share vocabulary or diverge completely. The structure of the producing holon is irrelevant to the consuming holon, which sees only the projection it was designed to receive.

We are reaching a point where the construction of such transformations is less expensive than the attempt to impose a single common standard. That changes the economics of ontology design fundamentally. And as LLM token costs become appreciable at scale, the amortisation argument grows stronger still: the AI expenditure is incurred once, during the authoring and refinement of the transformation, and is then retired. Every subsequent execution of that named query or ruleset is deterministic and token-free. The alternative — re-deriving the mapping on each query, or maintaining a standing prompt to mediate every exchange — compounds cost with every invocation. Persisting the transformation is not merely an engineering convenience; it is the economically rational choice.

---

Datascoping and Schema Portability

Two further structural features make the holonic model work cleanly in practice.

The first is datascoping. When a holon contains another holon, the containing holon may declare entities — employees, products, locations — that are made available to the contained holons. This is not duplication; it is inheritance of reference. A manufacturing sub-holon does not need to define what a “person” is; it receives that definition from the containing organisational holon, and specialises it as needed for its own domain. Entities defined at higher levels of the holarchy cascade downward, available to be refined but not re-invented.

The second is schema portability. A holon can supply, alongside its data, the ontological machinery needed to make sense of that data: SHACL shapes, RDFS class definitions, OWL axioms, or similar constructs from the semantic stack. The schema, in effect, travels with the data. This adds some overhead to each exchange, but it substantially increases portability. A consuming holon does not need prior knowledge of a producing holon’s internal model in order to work with the projection it receives; the projection arrives self-describing.

Together, datascoping and schema portability create a layered architecture in which the holarchy still maintains a minimal shared upper ontology at its apex — the definitions of core concepts that every part of the organisation shares — but as one descends into more nested, specialised holons, the rules and vocabulary for that specialisation travel with the data rather than being mandated from above.

---

The Analyst Case: Markov Blankets and Ontological Depth

What about queries that require genuine depth — analysts who need to cross holon boundaries, synthesise information from multiple projections, and ask questions the parametric query set was not designed to answer?

This is where ontologists, or ontological AI systems, come into their own. The analyst, in such a scenario, is effectively within the Markov blanket of the data in question — operating inside the boundary that separates what the system can perceive and reason about from what lies beyond it. They have access to the schema at that level, they understand the shape of what they are working with, and they can compose queries accordingly. For a human ontologist, this requires domain expertise and familiarity with the relevant vocabularies. For an AI system serving in an ontological capacity, it requires access to the schemas that travel with the data — which, under the holonic model, they do.

Named parametric queries handle the routine case. Ontological reasoning — human or AI — handles the exceptional case. The architecture accommodates both without privileging one at the expense of the other.

---

Graph Polymorphism

One final structural feature deserves attention. In object-oriented design, polymorphism allows the same method call to produce different behaviour depending on the type of the receiving object. Holonic graph architecture offers a direct analogue.

A query against a holon can be calibrated based on the role or profile of the querant. The same nominal request — “tell me about this employee” — produces different projections depending on whether the caller is HR, a line manager, a marketing analyst, or a senior executive. The transformation is deterministic, governed by the named query infrastructure and the access profile applied to the session.

This is not merely access control. It is a richer kind of semantic filtering, in which what the data means to the querant — what terms are used, what relationships are surfaced, what level of detail is appropriate — varies with context. The graph is genuinely polymorphic.

---

What Holonic Data Looks Like

The architecture that emerges from these principles is neither the Open World of the unified ontology ideal nor the Closed World of a siloed relational system. It is something better described as concentric openness: a nested structure in which each holon maintains its own ontological integrity, exposes carefully designed projections to adjacent and containing holons, and carries the schema needed to interpret those projections with it.

The consumer of what a holon produces does not need to know how the sausage is made. They receive a self-describing projection, governed by rules they can inspect, shaped to their role and context. The interior of the holon — its native ontology, its sensitive data, its local inference rules — remains protected without requiring the organisation to pretend that a single universal model can be imposed across every domain.

The upper holarchy still requires some shared vocabulary. You cannot have complete federation without any common ground. But that common ground can be genuinely minimal — core identifiers, foundational class definitions, the scaffolding that allows holons to refer to the same things — rather than the maximalist unified ontology that has so often proved unworkable in practice.

The hard part of ontology design, historically, has been making the unified model work everywhere. The insight the holonic model offers is that you do not need it to work everywhere. You need it to work at the level where things genuinely need to be shared, and to let everything below that level manage its own specialisation — with AI-assisted transformation handling the mappings between layers as a solved infrastructure problem rather than an ongoing manual burden.

The dream of the unified ontology was never misguided — it was mis-scoped. The question was never whether organisations should share a common understanding of their data. It was always at what level of abstraction that understanding needs to be common, and what can safely be left to the domain. Holonic architecture answers the first part of that question by minimising the shared surface. AI-assisted transformation answers the second by making the mappings between domains cheap enough to treat as infrastructure. Together, they make the aspiration of interoperable data achievable — not by demanding that everyone speak the same language, but by making translation fast, persistent, and economically rational.

---

Kurt Cagle is an author, ontologist, and knowledge architect. He serves as Chair of the W3C Holon Community Group and writes The Ontologist and Inference Engineer on Substack. Copyright 2026 Kurt Cagle.

Chloe Shannon is an AI collaborator and co-author working with Kurt Cagle on knowledge architecture, semantic systems, and the intersection of formal ontology with LLMs. Contact: chloe@holongraph.com.